The invention relates to the field of secure smart card components, or integrated circuit card.
When a smart card is inserted into a smart card reader, the reader supplies a power signal to the smart card. Now fed, the smart card can execute commands sent to it by the reader. The standard ISO 7816 normalises communication between a smart card reader and a smart card. Reference is made here for example to standard ISO 7816-3 section 10.2, of reference ISO/IEC JTC 1/FC 17 N2837 for example, dated Sep. 7, 2005.
In particular, this protocol provides that, when it sends a command to the card, the reader triggers a counter which is incremented progressively with time. If the counter reaches a value corresponding to the expiration of a duration called Waiting Time (WT) from the sending of the command without receipt of a response from the card, it is considered that the card will no longer respond. The reader cuts the power of the card to reinitialise it. According to the standard ISO 7816, the duration WT is calculated at each reinitialisation of the smart card component, especially as a function of the clock frequency of the communications interface ISO 7816 (between the reader and the card) applied by the reader and of the speed of communication of the communications interface ISO 7816 negotiated during initialisation. For example, the duration WT is equal to 714 ms for a frequency of 5 MHz and a default communication speed (that is, the speed according to which the duration of a bit on the communications interface ISO 7816 is equal to 372 clock strikes). During execution of a command requiring more than the duration WT, the card can periodically send a predetermined message, called protocol byte, to request more time from the reader. According to the standard ISO 7816, this is an byte 0x60. In response on receipt of the protocol byte, the reader reinitialises the counter.
This mechanism proposes an effective response to blockage of a card during its “normal” use.
However, this mechanism can pose a problem for a card undergoing attacks. It is known that to secure the operating of a smart card component, for example a microcontroller, manufacturers use security locks implanted in the code of the component. An attack by a fault injection consists of perturbing the component to divert it from its normal behaviour and try to make it “jump” its security locks. Such an attack by fault injection is achieved for example by sending a light pulse to the smart card component at an instant corresponding to the execution of a determined instruction.
To test the security of its smart cards facing such attacks, a smart-card manufacturer can be encouraged to carry out attacks himself, or to have attacks carried out by a third party, for example a certification organisation.
During an attack by fault injection, injected errors completely divert the component and the latter can be prompted to execute a code different to that provided by the developer of an application. It often happens that the card executes a code loop whereof the execution is never terminated due to an injected fault: this is called an infinite loop. This can happen if for example the injected fault modifies the output condition of the loop. If the output condition can no longer be retrieved in the code, the card will then stay in its loop.
In parallel with continuous execution of this code loop, the card automatically sends the protocol byte (byte 0x60) to request a time extension. This iteration prevents the reader from taking over. The reader therefore remains in wait status.
The standard ISO 7816 proposes no mechanism for reacting when the card executes such an infinite loop.
However, this type of situation occurs frequently when the attempt is made to validate the resistance of implementation against attacks by fault injection. In this case, the sole solution for continuing analysis for the evaluator is to manually take the card from the reader and reinsert it. This loses much time when the evaluator is conducting manual attacks (because the reader and the card are located in a protective caisson containing the laser, the fact of removing the card and reinserting it requires the evaluator to respect strict procedure since it is extremely dangerous to be exposed to laser beams).
This is even more problematic when automatic attacks are launched (throughout a night, for example) since when perturbation generates an infinite loop the attacks stop and the evaluator therefore loses much time. This happens frequently during attacks by fault injections and remains a major problem.